Proliferation of cloud-based content management services and rapid adoption of cloud-based collaboration have impacted the way personal and corporate electronically stored information objects (e.g., files, images, videos, etc.) are stored, shared and managed. One benefit of using cloud-based service platforms is the ability to securely create and share large volumes of content among trusted collaborators. For example, a large enterprise (e.g., company, firm, etc.) with thousands of users (e.g., employees, customers, etc.) and many terabytes of content might use a cloud-based service platform to efficiently and securely facilitate content access to various individual users and/or collaborative groups of users. The users can have access to content that the users own (e.g., resulting from a user's own creation that had been uploaded to the cloud-based service platform, etc.) as well as to content shared with other users. The cloud-based service platform often implements collaboration components (e.g., preview generators, commenting tools, workflow tools, etc.) to facilitate content sharing.
To increase the utility of content sharing and to enrich user experiences, software applications and web services are developed and deployed. Such applications and web services interface with the cloud-based service platform resources using application program interfaces or APIs for access to various portions of the shared content. In certain settings and, in particular, when implementing certain types of applications (e.g., web applications, mobile applications and/or variations thereof), collaboration involved with respect to the shared content might include combinations of multiple users rather than a single user, some of which of the multiple users are content owners, and some of which multiple users are not content owners, but nevertheless need some ways (e.g., secure ways) to access portions of the shared content.
Unfortunately, legacy approaches that apply to web applications that provide access to shared content in a cloud-based service platform are insufficient. Specifically, some approaches might provision content access for a given first type of transaction (e.g., user file access) based on a successful authentication of a user (e.g., human) at the cloud-based service platform, however access to content other than that which is available by the authenticated user might be needed for carrying out a second type of transaction (e.g., system file access), which second type of transaction might apply to a second type of user. Legacy approaches introduce burdensome requirements (e.g., by requiring separate authentication protocols to be carried out for each transaction type). Such legacy techniques are deficient, at least because (1) the user is repeatedly challenged to provide a username and password or other credentials, and (2) a master administrator or similar such super-user would need to manage multiple sets of credentials for each supported type of transaction and/or for each separate type of user. In addition to the aforementioned burdens, the legacy approaches are wasteful, at least inasmuch as not all client services require user authentication in order to perform its functions, and therefore the authentication challenge is not only unneeded but also might negatively impact overall user experience and/or system performance. This situation is exacerbated with the advent of microservices (e.g., web services). Legacy approaches to providing such microservices fail in that they either are allowed or disallowed based on a binary “Yes/No” determination even though the particular microservice might be able to perform its functions in a customized manner even in absence of any form of user authentication.
What is needed is a technique or techniques to improve over legacy and/or over other considered approaches. Some of the approaches described in this background section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.